Subject: Re: Capabilites - include also configuration ?

From: [email-masked] (David Matusow)
Date: Wed, 14 Jul 93 13:05:37 -0400

>   When capabilities are exchanged, a list of already known DLSw nodes can
>   be sent. As a result, one (or more) DLSw nodes can serve as 'name servers'
>   While other nodes can connect those and receive an update list DLSw nodes.
>   The name server may have a preconfigure list of nodes, and it can also
>   collect them dynamically, when other nodes establish connection.
>   
>   
>   Elazar (Azi) Ronen, RADLINX

It seems that we are quickly moving towards implementing a minimalist
APPN NN.  We are in the process of adding so many towers to DSL (though
they may not be options, so they are no TOWERS, but base) that it will
soon fall over from its weight.

I don't disagree that this would be a great tool for our customers, but
this doesn't seem like something that should be implemented on an initial
implementation AND it would seem like just the ability to do this would
be a good item for inclusion AS a capability.  In this way, it becomes an
objective, but not a base function.

I also think that this may be taken further into an actual name server
function.  This would reduce the implementation requirements for each
box (reducing cost to our customers) while providing communication to
provide the information to a server.  This would allow a DLS node to
provide information that it has cached, but would not require a full-flown
DS.

Does any of this sound reasonable?

David Matusow
Hypercom